RBAC 权限模型
uni-admin 的权限系统基于经典的 RBAC（Role-Based Access Control）模型。核心关系链路：
用户 → 角色 → 权限 → 菜单
text
一个用户可以拥有多个角色，一个角色可以拥有多个权限，权限与菜单关联。对应的数据库表：
| 表名 | 用途 |
|---|---|
uni-id-users | 用户表，role 字段存储角色信息 |
uni-id-roles | 角色表，存储角色定义和权限列表 |
uni-id-permissions | 权限表，存储权限标识和名称 |
配置流程
第一步：创建权限标识
在 uni-admin 的"系统管理 → 权限管理"中新增权限。权限 ID 是唯一标识符，命名建议采用"操作+资源"的格式，如：
read— 查询信息read-uni-id-users— 读取用户数据read-uni-id-roles— 读取角色数据update-user— 更新用户信息
第二步：创建角色并分配权限
在"角色管理"中创建角色（如 member，普通成员），并勾选该角色拥有的权限标识。
第三步：创建用户并分配角色
在"用户管理"中创建用户，勾选"可登录应用"并分配角色。
官方文档的坑
按照 uni-admin 官方文档的步骤操作后，普通用户登录系统可能会遇到"权限校验未通过"的错误。这不是操作错误，而是文档描述不完整导致的。
坑一：可登录应用 ≠ 角色权限
官方文档中将"可登录应用"和"角色权限"混为一谈。实际上，用户能否登录管理后台取决于"可登录应用"配置，与角色权限无关。未勾选可登录应用的用户会提示"此账号未在该应用注册"，而非权限不足。
坑二：权限标识需要精确到数据库表
即使按照文档创建了 read 权限并分配给角色，用户仍然无法读取用户管理列表的数据。原因是 uni-admin 的数据库 Schema 在字段级别设置了更细粒度的权限控制。
每个字段的 read 权限不是一个简单的 true/false，而是一个权限标识字符串（如 read-uni-id-users）。用户必须拥有这个精确的权限标识才能读取对应字段的数据。
因此，需要额外创建以下权限标识：
| 权限 ID | 说明 | 关联字段 |
|---|---|---|
read-uni-id-users | 读取用户表字段 | uni-id-users 表的字级权限 |
read-uni-id-roles | 读取角色表字段 | uni-id-roles 表的字级权限 |
read-uni-stat-result | 读取统计结果 | uni-stat-result 表 |
read-opendb-app-list | 读取应用列表 | opendb-app-list 表 |
创建后，将这些权限分配给 member 角色。
坑三：首页统计模块的权限
普通用户登录后，首页会加载设备统计、用户注册等数据。这些数据来自 uni-stat-result 和 opendb-app-list 两个表。如果用户没有对应的读取权限，首页会报"权限校验未通过"错误（但其他功能可能正常）。
解决方法：继续在权限管理中添加 read-uni-stat-result 和 read-opendb-app-list 权限标识，并分配给角色。
权限配置完整链路
1. 权限管理 → 新增权限标识（read-uni-id-users, read-uni-id-roles 等）
↓
2. 角色管理 → 创建角色 → 勾选权限标识
↓
3. 用户管理 → 创建用户 → 勾选可登录应用 → 分配角色
↓
4. 菜单管理 → 为菜单项配置权限（可选，控制菜单可见性）
↓
5. 测试：使用普通用户登录，验证功能权限
text
登录验证
配置完成后，使用普通用户登录管理系统：
- 能看到左侧菜单（由菜单权限控制）
- 能读取用户列表数据（由数据库字段权限控制）
- 无法新增、修改、删除数据（未分配写权限）
如果仍然出现"权限校验未通过"的提示，需要检查具体报错的数据库表名，然后为该表添加对应的读取权限标识。
↑